FIG. 1 illustrates a computer 20 constructed in accordance with the prior art. The computer 20 includes a central processing unit 22, which communicates with a set of input/output devices (e.g., keyboard, mouse, video monitor, printer, and the like) 24 over a system bus 26. Also connected to the system bus is a primary memory (e.g., volatile memory, such as a RAM) 28 and a secondary memory (e.g., mass storage, such as a disk) 30. The secondary memory stores a set of software objects 32. The software objects 32 are characterized by an object list 34, which includes header entries 36 and a central directory 38, which provides a short-hand characterization of the header entries 36.
An application program 40 stored in primary memory 28 is executed by the central processing unit 22. The application program 40 invokes objects 32 to perform specified functions. In particular, the application program 40 accesses a primary memory object index 42, which basically corresponds to the object list central directory 38, as discussed below. The primary memory object index 42 allows the application program 40 to identify and load invoked objects 32 stored in secondary memory 30. After being invoked, the selected objects 44 are resident in primary memory 28.
FIG. 2 illustrates an object list 34 in accordance with the prior art. The object list 34 includes a set of object list entries 36A-36N. Each entry includes an object name 50, a header 52, and data 54. The header 52 includes information, such as object version, general purpose bit flags, compression method information, a cyclic redundancy check of uncompressed data, compressed data size, uncompressed data size, filename length, and the like. The data 54 includes the instructions or other information associated with the object. Since each entry 36 can be relatively large, a central directory 38 is associated with the object list 34. The central directory includes a set of central directory entries 48A-48N corresponding to the object list entries 36A-36N. Each central directory entry 48 includes an object name 50 and a pointer 60 to the location of the corresponding object list entry 36.
As previously indicated, the primary memory object index 42 is typically implemented as the central directory 38 of the object list 34. The problem with this approach is that the central directory 38 can be relatively large because it includes such information as the object name, the object's location, and miscellaneous information about the object. It is well known that the performance of a computer is largely contingent upon its efficient use of primary memory. An oversized primary memory object index can lead to inferior computer performance.
The foregoing problem is more fully appreciated in connection with a specific example. JAVA.TM. is a well known computer language developed and licensed by Sun Microsystems, Inc., Mountain View, Calif., the assignee of the present invention. An application program 40 written in JAVA.TM. is supported by a large object list. The central directory 38 of the object list 34 is scanned through a bootclasspath or application classpath, resulting in the construction of the primary memory object index 42. The resultant primary memory object index 42 is relatively large.
The JAVA.TM. Development Kit (JDK.TM.) is an object list 34 which contains the software and tools that developers need to compile, debug, and run applets and applications written using the JAVA.TM. programming language. Java Archive (JAR) is a platform-independent file format that aggregates many files into one. Multiple JAVA.TM. applets and their requisite components (e.g., class files, images and sounds) can be bundled in a JAR file and subsequently downloaded to a web browser in a single Hypertext Transport Protocol (HTTP) transaction, greatly improving the download speed. The utility "java.util.jar" provides classes for reading and writing the JAR file format. The JAR file format is based on a "ZIP" file format that is used in JAVA.TM.. The utility "java.util.zip" provides classes for reading and writing the standard ZIP and GZIP file formats. Some of the classes associated with "java.util.zip" that are used by "java.util.jar" include: DeflaterOutputStream, which is a class to implement an output stream filter for compressing data in the "deflate" compression format; InflaterinputStream, which is a class to implement a stream filter for uncompressing data in the "deflate" compression format; ZipEntry, which is a class to represent a ZIP file entry, ZipFile, which is a class to read entries from a zip file; and ZipException, which is a class to handle exceptions. Some of the classes that are used by "java.util.zip" include: checksum, which is an interface representing a data checksum; CRC32, which is a class that can be used to compute the thirty-two bit cyclic redundancy check of a data stream; and ZipEntry, which is a class used to represent a ZIP file entry.
In JDK 1.2, for each ZIP or JAR file on the bootclasspath or application classpath, the file's central directory 38 is scanned and a primary memory object index 42 is built. In the prior art, all of the information from the central directory 38 is loaded into primary memory 28. This includes the name of the ZIP entry, it's offset in the ZIP file, and about 24 bytes of additional information. This results in about 4,500 ZIP entries in a primary memory object index 42 that takes up approximately 424 KB. This relatively large primary memory footprint is expected to grow as additional classes are added to support JAVA.TM..
In view of the foregoing, it would be highly desirable to provide a technique for loading objects from a primary memory index that has a relatively small primary memory footprint. Such a technique could be used, for example, to reduce the primary memory footprint of the ZIP index for the core JAVA.TM. classes. Such a technique could also be used for applications that use large JAR files.